AIを開発に使ってうまくいったパターンを語る会2025 開催レポート
shokai.iconがCosense開発で実践し、確かな成果を上げた「AI活用の成功パターン」をまとめました
最近、準備・開催・事後レポートをそれぞれ1〜2時間ずつで素早くやる形式を模索しています
1. 序論：なぜ「速さ」ではなく「信頼性」に挑んだのか
shokai.iconはAIコーディングエージェントの普及により全世界的に開発速度が劇的向上し、それに伴い「粗製濫造されたコードによる品質低下」と「障害対応の難易度爆増」という副作用が伴うと予測しました。この流れはオープンソースのライブラリを使ったり他社のAPIと連結したサービスを構築している以上、影響を避ける事はできないので、特にAIをレビューやドキュメントの読み解きに使う方法を模索しました。
開発においては
社内には個人開発者が多くいるから、プロトタイピングのような「失敗してもよい」場面での活用は個々人に任せれば十分に切り開いてくれるだろう 一方Helpfeel社は2023年からAIをプロダクトに組み込んできた為、こういう時にこうハルシネーションが起こるという話も頻繁に行われていた為、AIの出力に懐疑的な慎重派も少なからずいる 長期運用するプロダクト開発の本流においては、shokai.iconは「いかにAIの出力ブレを抑え、人間が責任を持てる信頼性の高い成果物を生み出すか」という点に注力すると、全社的なバランスが取れるだろう
と考え、実証実験を重ねてきました。
という位置づけの話をする会だったので、もはや社内では当たり前のとなっている開発技法については、一切触れませんでしたshokai.icon
2. 結論：「生成」から「読み合わせ」へ
「信頼できるアウトプット」は、以下の3つのアプローチによって確立されました
例えば、「ドキュメントを1項目読む → 全ファイルを検索して1つずつチェック → 人間に確認する → 次の項目へ」のような二重ループ構造で指示し、人間が検証可能な粒度で確実にタスクを遂行させる
AIにコードレビューをさせるためのガイドラインを作る過程で、人間側が「こうしろ」「なぜそうするべきなのか」を言語化せざるを得なくなり、結果として暗黙知が形式知化される 3. AIラバーダッキング
複雑な仕様やデータフローをAIに「説明」する過程で、人間自身の思考が整理され、解決策が導き出される
高精度に言語化できていれば、生成されるコードも意図した通りのものとなる
3. 実践事例：AI開発でうまくいったパターン
上記の結論を裏付ける、具体的な成功事例を紹介します
① レビューとガイドライン作成の循環
手法: 過去のPRとレビューコメントをAIに学習させ、自分の代理としてレビューを行わせた
最近はこれをClaude Code Github Actionsで実行しているshokai.icon
手法: ほぼ同じアーキテクチャであるHelpfeelのコードを分析して方針を固め、ガイドライン化し、Cosenseのコードに適用しながら調整していった
成果: 「このmodelをガイドラインに沿ってTypeScript化して」で一発でいい感じに変換できるようになった
② ドキュメント読み合わせによるマイグレーション
手法: 公式の移行ガイドとソースコードをAIに「読み合わせ」させ、項目ごとに影響調査と修正を行わせた
雑に「読んで更新して」と指示するのではなく、1項目ずつ解説→サービス側のソースコードを検索して修正箇所をリストアップ→人間側に了解を取る→次の項目へ、と少しずつ確実に進める
成果: res.statusの仕様変更など、人間が見落としがちな微細な差異も正確に検出・修正できた
③ 複雑な仕様の壁打ち解決（5月）
手法: AIラバーダッキング。状態管理が複雑な機能の実装について、現状と理想の挙動をひたすらAIに説明・相談した 成果: 対話の中で複雑なデータフローが整理され、実装の糸口が見つかった。（AIが解いたというより、説明することで人間が解いた）
今の挙動、理想的な挙動、データの流れ・イベントの順序について語り合っていたら
https://scrapbox.io/files/6950ec91ca345655eb6902a9.png
すっきりして解決した
https://scrapbox.io/files/6950ec95ded1eaa49f6d987d.png
④ 未知の領域の調査と実装
手法: 数年前にbalar.iconが作った決済機能（買い切り）の実装を参考に、AIにコピペベースで新機能（サブスク）を作らせた
成果: AIは設計は苦手だが「文脈を読んだコピペ」は天才的に上手いことが判明
立ち上げの初速を重視した。DRYではない汚いコードができてしまったが、後で人間が直せば良い。
さっさと直さないと決済できなくてサ終してしまうので、10日で移行したshokai.icon
手法: Deep Research後にAIを質問攻めする。さらに用語のリストを出力し、個別のCosenseページを作成して定義と関係性を整理し直し、未知の概念を深く理解する
⑤ 運用・デバッグへの応用（9月〜11月）
手法: 巨大なツールをいきなり作らせず、検証可能な小さなCLIツールを複数作らせてから合体させた
成果: 非常に複雑なデータ移行（ファイル移動、ページ本文修正、サムネイル作成、全文検索登録）を、サービス無停止で一発成功させた
手法: 本番環境のコードをCodex CLIに読ませ、「ここが怪しいから調べて」と無茶振りを繰り返してアタリをつけた。 https://scrapbox.io/files/69256e1010003d6d446b0eee.png
⑥ レポートという形式による「切り口」の発見（10月）
手法: 結論のない発表資料や文字起こしをAIに渡し、レポートという形式でまとめさせた。
成果: AIが情報の辻褄を合わせる過程で、「対策は寝かせる・隔離・検知の3つ」という人間も気付いていなかった新しい「切り口」が発見され、理解の次元が上昇した。 4. ディスカッションダイジェスト
参加者から共有された独自の工夫や、発表内容に対する深堀り議論が行われました。
1. レビューを楽にする「AIによる目grep」フォーマット
工夫: 大量のリファクタリングなど、AIに広範囲の単純作業を行わせた際、その結果を人間が確認（レビュー）するのは大変である。そこで、AIに「変更箇所と対応するGitHubの行リンク（URL）」をテーブル形式で出力させる手法が共有されました。
メリット: コードの該当箇所を一覧で見られるため、人間が「目grep」で高速に確認でき、見落としを防げます。 コツ: いきなり最終的なテーブルを作らせるのではなく、一度変更箇所をリストアップさせるなど、中間生成物を挟むことでAIの抜け漏れを防げます。
2. ライブラリ更新手順書の汎用性と意外な効果
発見: 手順書の指示が「Changelogやリリースノートを確認せよ」といった抽象的なものであるため、npmパッケージだけでなく、RubygemsやDocker imageの更新などにも応用可能であることが判明しました（AIが勝手に公式ブログなどを探しに行って解説してくれる）。 3. AIラバーダッキングによる複雑な手順の設計
複雑なデータマイグレーションの手順を考える際、Claude Codeと壁打ち（ラバーダッキング）をすることで頭の中が整理されたという事例が出ました。 人間一人で考えると不安になるような複雑な依存関係やエッジケースに対し、AIに計画を話すことで「このパターンはおかしい」と粗探しをしてもらえます。
ツールの使い分け
現状では、手元のコードを扱える「ローカル型（Claude Code等）」と、推論能力や検索に強い「クラウド型（ChatGPT等）」を、用途に合わせて使い分けている状況です。
4. 「1つずつ処理」とReasoning Tokensの関係
発表内で触れられた「1項目ずつ処理させる」アプローチは、プロンプトに「ラバーダッキングしながらやって」と指示することと同義ではないか？という指摘がありました。
特に最近のAI（o1やClaude 3.7以降）が搭載しているreasoning tokensやThinking機能は、内部的にこの「自己対話（ラバーダッキング）による試行錯誤」や「計画の立案」を行っていると言えます。 メリット: 人間が明示的に「1つずつ」と指示することで、AIのコンテキスト溢れによる品質低下を防ぎ、確実な遂行を促すことができます。
5. 会で語られたツールの紹介
Cosenseの巨大なプロジェクトから、AIやLLMが必要とする文脈（コンテキスト）だけを適切に切り出して渡すための機能
ページ本文だけでなく、関連ページ（1-hop linkや2-hop link）も含めて1つのテキストファイルとしてエクスポートする
AIがデータの構造を理解しやすい
ただのエクスポートファイルではなく、冒頭には「まずはメインページから読み、リンクを辿るように」といったAI向けのガイド（ある種のプロンプトインジェクション）が含まれている為 事例: NotebookLMでの検索や、Claude CodeなどのAIコーディングエージェントに実装方針や仕様を伝える際のDesign Docsとして利用
GitHubリポジトリを読み込んでドキュメント化し、AIに質問できるようにするツール
メジャーではない（準メジャー級の）ライブラリの仕様について、他のLLMが間違った知識を持っている場合でも、DeepWikiのチャット機能を使うと正しいコードや回答を得られることがある
ライブラリの更新（DependabotによるPull Requestなど）をAIにレビューさせるための具体的な指示書
単に「レビューして」と頼むのではなく、リリースノートの確認、依存関係の分析、コード内の利用箇所の特定など、shokai.iconが重視する観点を手順として明文化
効果: Claude CodeやDevinなどのAIエージェントにこの手順書を渡すことで、毎回同じ観点での高品質なレビューを自動化でき、人間が何度も同じ指摘をする手間を省ける
ChatGPT
Web検索ツールを併用することで正確な情報が得られやすいため、日常的な開発・調査に適しています
Gemini
通常モードではハルシネーションのリスクが高いが、Deep Research機能に関してはChatGPTよりも優れており、学術的な用語を用いた「知的な広がり」のあるレポートを生成してくれる 使い分け
即物的な問題解決にはChatGPT、深い調査や新しい切り口の発見にはGeminiのDeep Researchという使い分けを推奨
ただし、やりすぎ注意
一番使用感の良いAIコーディングエージェント
特に指示から作業プランへの分解（plan mode）の精度、確認を求めてくるタイミングの適切さなど、一番shokai.iconのリズムに合うツール
従量課金制なので、使ってないアカウントの棚卸しや、ROI説明の作業が楽なのも会社的にうれしい
一番気軽に無茶振りできるAIコーディングエージェント。
単純にコードを追いかけ続けて変な所を見つける能力が高く、シート制で月定額なので無茶振りさせやすい
AI側の動作中に確認モードのオンオフができなかったりする所は使いにくい
同じworkspaceの他人のchatが見れるのは良い。やり方の共有ができる。
使用感とか精度とか、AIの作業結果を手元のパソコンに持ってきて動かす手間とかがなんかリズム合わなくて使わなくなったshokai.icon
この振り返りレポートの制作方法